Method of applying for credit at a self-checkout

ABSTRACT

A method performed by at least one computing device. The method includes receiving a credit request from a self-checkout device before a customer completes an instore checkout process and sending a request for a Uniform Resource Locator (“URL”) to one or more authentication computing devices. The authentication computing device(s) send the URL to the mobile device. The method includes sending a credit application to the mobile device after the customer selects the URL, receiving a submission of the credit application from the mobile device, approving credit based on the submission, and forwarding a code to the mobile device. The code indicates that the credit is to be used to complete the instore checkout process when scanned by the scanner.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention is directed generally towards methods performed bya self-checkout unit.

Description of the Related Art

Retailers are moving away from traditional cashier staffed registers.Instead, self-checkout units are becoming a primary way in whichcustomers scan, pay, and bag their purchases. Unfortunately, unlike attraditional registers, there is no way for retailers to offer credit oraccept credit applications at these self-checkout units.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

FIG. 1 is a diagram of a system that includes computing devices and isconfigured to allow customers to apply for credit at a self-checkoutregister or device.

FIG. 2 is a flow diagram of a method performed by the self-checkoutdevice of FIG. 1 .

FIG. 3 illustrates an exemplary first screen displayed by a displaydevice of the self-checkout device of FIG. 1 .

FIG. 4 illustrates an exemplary second screen displayed by the displaydevice of the self-checkout device of FIG. 1 .

FIG. 5 illustrates a confirmation window displayed by the display deviceof the self-checkout device of FIG. 1 .

FIG. 6 illustrates exemplary interactions between the computing devicesof FIG. 1 .

FIG. 7 is a flow diagram of a method performed by an applicationprocessing service implemented by one or more of the computing devicesoperated by a credit card issuing company.

FIG. 8 illustrates an exemplary screen displayed by a text applicationimplemented by a mobile device of FIG. 1 .

FIG. 9 illustrates an exemplary first screen displayed by a web browserimplemented by the mobile device of FIG. 1 .

FIG. 10 illustrates an exemplary second screen displayed by the webbrowser implemented by the mobile device of FIG. 1 .

FIG. 11 illustrates an exemplary third screen that requests customersupplied information and is displayed by the web browser implemented bythe mobile device of FIG. 1 .

FIG. 12 illustrates an exemplary approval screen displayed by the webbrowser implemented by the mobile device of FIG. 1 .

FIG. 13 is a flow diagram of a method performed by the mobile device ofFIG. 1 .

FIG. 14 is a diagram of a hardware environment and an operatingenvironment in which the computing devices of the system of FIG. 1 maybe implemented.

FIG. 15 is a diagram of a hardware environment and an operatingenvironment in which the mobile device of FIG. 1 may be implemented.

Like reference numerals have been used in the figures to identify likecomponents.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram of a system 100 operated at least in part by aretailer 102, a credit card issuing company 104, and an authenticationentity 106. The retailer 102 includes a retail computing system 108connected to at least one Self-Checkout (SCO) register or device 110.The SCO device 110 includes a scanner 112 (e.g., a barcode scanner) anda display device 114. The retail computing system 108 may be directlyconnected or connected by one or more networks 120 (described below) tothe SCO device 110. The retail computing system 108 and the SCO device110 may each be implemented by one or more computing devices, which mayeach be implemented as a computing device 12 described below andillustrated in FIG. 14 .

Referring to FIG. 1 , the SCO device 110 is configured to be operated bya customer 122 having a mobile device 124 (e.g., a cellular telephone)with a display device 126 (e.g., a conventional touch screen). Forexample, the customer 122 may purchase one or more items 128 using theSCO device 110. As will be described below, the customer 122 may alsouse the SCO device 110 and the mobile device 124 to apply for credit.Enabling the customer 122 to request credit at the SCO device 110 andcomplete the application process using the mobile device 124 gives thecustomer 122 the opportunity to save money by applying for credit whenit is needed in a quick and easy manner. The mobile device 124implements a text application 116 and a web browser 118. By way ofnon-limiting examples, the mobile device 124 may be implemented as amobile communication device 600 described below and illustrated in FIG.15 or as a computing device 12 described below and illustrated in FIG.14 .

Referring to FIG. 1 , mobile services are provided to the mobile device124 by a mobile service provider or carrier 170. The carrier 170operates one or more computing devices 172 configured to communicateover the network(s) 120. The computing device(s) 172 store customerinformation 174 about the customer 122. By way of a non-limitingexample, the customer information 174 may include one or more of thefollowing:

1. Mobile telephone number;

2. First Name;

3. Last Name;

4. Address;

5. Extended Address;

6. City;

7. Region;

8. Postal Code;

9. Email Address; and

10. Status.

The computing device(s) 172 may each be implemented as the computingdevice 12 described below and illustrated in FIG. 14 .

Referring to FIG. 1 , the credit card issuing company 104 operates oneor more computing devices 130. The computing device(s) 130 implement asecurity gateway 132, a web server 134, a proxy server 136, anapplication processing service 140, and a Short Message Service (“SMS”)module 142. The security gateway 132 is configured to communicate withthe SCO device 110 over the network(s) 120. By way of a non-limitingexample, the security gateway 132 may be implemented as a Forum SentryAPI Security Gateway provided by Forum Systems. The web server 134 andthe proxy server 136 are both connected to the network(s) 120. The webserver 134 is configured to generate an apply website 138. Theapplication processing service 140 is configured to communicate with thesecurity gateway 132 and/or the web server 134. The Short MessageService (“SMS”) module 142 is configured to communicate with theapplication processing service 140. The SMS module 142 may beimplemented by middleware. By way of a non-limiting example, thecomputing device(s) 130 may each be implemented as the computing device12 described below and illustrated in FIG. 14 .

The authentication entity 106 operates one or more authenticationcomputing devices 150 configured to communicate over the network(s) 120.The authentication computing device(s) 150 may implement a UniformResource Locator (“URL”) generator 152, a device authentication service154, an SMS service 156, a pre-fill service 158, and/or a token service160. By way of a non-limiting example, the authentication computingdevice(s) 150 may each be implemented as the computing device 12described below and illustrated in FIG. 14 .

FIG. 2 is a flow diagram of a method 200 performed by the SCO device 110(see FIG. 1 ). As mentioned above, the SCO device 110 (see FIG. 1 )includes the display device 114 (see FIGS. 1 and 3-5 ) that may beimplemented as a convention touch screen. Referring to FIG. 3 , in firstblock 210 (see FIG. 2 ), the display device 114 of the SCO device 110(see FIG. 1 ) displays a screen 212 to the customer 122 (see FIG. 1 )including a selectable user input 214. By selecting (e.g., tapping on)the user input 214, the customer 122 (see FIG. 1 ) starts a creditapplication process. Referring to FIG. 1 , in next block 220 (see FIG. 2), the SCO device 110 receives an indication that the customer 122 hasselected the user input 214 (see FIG. 3 ).

Referring to FIG. 4 , in block 230 (see FIG. 2 ), the display device 114of the SCO device 110 (see FIG. 1 ) displays a screen 232 including oneor more inputs 234 for a telephone number associated with the mobiledevice 124 (see FIGS. 1, 6, and 8-12 ). The screen 232 may also includeinformation 236 regarding a credit card product being offered. Referringto FIG. 2 , in block 240, the SCO device 110 receives the telephonenumber input by the customer 122 (see FIG. 1 ) into the input(s) 234(see FIG. 4 ). For example, in block 240, the customer 122 (see FIG. 1 )may enter the telephone number into the input(s) 234 (see FIG. 4 ) andclick or tap on a selectable user input 242 (e.g., a button). As shownin FIG. 4 , the input(s) 234 may include numerical input buttons 244.

Optionally, after the SCO device 110 receives the telephone number, thedisplay device 114 may display a confirmation message or window 246 (seeFIG. 5 ). Referring to FIG. 5 , the confirmation window 246 may informthe customer 122 (see FIG. 1 ) that a text message is being sent to thetelephone number received in block 240 (see FIG. 2 ). The confirmationwindow 246 may include a selectable user input 248 that when selected bythe customer 122 (see FIG. 1 ) allows the customer 122 to use thescanner 112 (see FIG. 1 ) to begin scanning the item(s) 128 (see FIG. 1) to be purchased at the SCO device 110 (see FIG. 1 ).

Referring to FIG. 2 , in block 250, the SCO device 110 (see FIG. 1 )sends a credit request 252 (see FIG. 6 ) including SCO information 251(see FIG. 6 ) to the application processing service 140 (see FIGS. 1 and6 ). Referring to FIG. 6 , in the embodiment illustrated, the creditrequest 252 is sent by the SCO device 110 to the security gateway 132,which forwards the credit request 252, as a credit request 254, to theapplication processing service 140. The credit request 252 may beimplemented as a JSON packet. The security gateway 132 may be an exposedRESTful endpoint configured to receive the credit request 252 (e.g., aJSON packet). The SCO device 110 may access the exposed RESTful endpointusing a URL. In other words, the SCO device 110 may send the creditrequest 252 (e.g., a JSON packet) to the URL associated with thesecurity gateway 132. The SCO information 251 may include one or more ofthe following:

a. Retailer Identifier (“ID”);

b. Country code;

c. Store Number;

d. Timestamp;

e. Register Number;

f. Client ID; and

g. Mobile Telephone Number;

Referring to FIG. 1 , after the SCO device 110 sends the credit request252 (see FIG. 6 ), the SCO device 110 waits for the customer 122 to usethe scanner 112 to scan the item(s) 128.

In block 260 (see FIG. 2 ), the customer 122 uses the scanner 112 toscan the item(s) 128 and initiates checkout on the SCO device 110. Thus,in block 260 (see FIG. 2 ), the SCO device 110 receives identificationsof the item(s) 128, looks up an associated price for each of the item(s)128, and determines a total transaction price. By way of a non-limitingexample, the SCO device 110 may look up the prices using the retailcomputing system 108.

In block 270 (see FIG. 2 ), the SCO device 110 receives payment for theitem(s) 128. If the customer 122 was not successful at obtaining credit,in block 270 (see FIG. 2 ), the SCO device 110 receives a standard formof payment from the customer 122, such as cash, a check, a credit card,or other form of payment. On the other hand, if the customer 122successfully obtained the credit, the SCO device 110 receives a code,which the customer 122 scanned from the display device 126 of the mobiledevice 124 using the scanner 112. Referring to FIG. 12 , in theembodiment illustrated, the code has been implemented as a paymentbarcode 274. However, the code may be implemented as another type ofdynamically generated and/or encrypted value or image. By way of anon-limiting example, the code may include encrypted paymentinformation.

Referring to FIG. 6 , an arrow 276 represents the customer 122 (see FIG.1 ) scanning the payment barcode 274 using the scanner 112 (see FIG. 1). The SCO device 110 forwards the payment barcode 274 to theapplication processing service 140 via the security gateway 132. Theapplication processing service 140 uses credit associated with thepayment barcode 274 to complete the purchase. Thus, at this point, thecustomer 122 (see FIG. 1 ) successfully completed the credit applicationprocess and used that credit to purchase the item(s) 128 (see FIG. 1 ).

Referring to FIG. 2 , the method 200 terminates after the block 270.

FIG. 7 is a flow diagram of a method 300 performed by the applicationprocessing service 140. In first block 310, referring to FIG. 6 , theapplication processing service 140 receives the credit request 254(e.g., a JSON packet) from the SCO device 110. As mentioned above, theSCO device 110 may send the credit request 252 to the security gateway132, which forwards the credit request 254 to the application processingservice 140.

In block 315 (see FIG. 7 ), the application processing service 140 sendsa URL request 316 for an authentication URL 318 to the URL generator 152(see FIG. 1 ) implemented by the authentication computing device(s) 150.The URL request 316 may include a target URL 317 and the SCO information(e.g., appended to the target URL as variables). The target URL 317 maybe URL of the apply website 138 (see FIGS. 1 and 9-12 ) operated by theweb server 134. By way of a non-limiting example, in block 315 (see FIG.7 ), the URL generator 152 (see FIG. 1 ) may be implemented as Payfoneand the application processing service 140 may call Payfone and use anapplication programming interface (“API”), such as /getAuthUrl, torequest the authentication URL 318. The URL generator 152 (see FIG. 1 )generates the authentication URL 318 and sends it in a message 319 tothe application processing service 140.

In block 320 (see FIG. 7 ), the application processing service 140receives the message 319 with the authentication URL 318 from the URLgenerator 152 (see FIG. 1 ) in response to the URL request 316. Inaddition to the authentication URL 318, the application processingservice 140 may also receive a description, a request ID, an operatorname, and a status.

Next, in block 325 (see FIG. 7 ), the application processing service 140sends an SMS request to the SMS service 156 (see FIG. 1 ) implemented bythe authentication computing device(s) 150. In the embodimentillustrated, the application processing service 140 sends a create SMSrequest 326 to the SMS module 142, which creates and sends an SMSrequest 328 to the SMS service 156 (see FIG. 1 ). The create SMS request326 may include a message, the authentication URL 318, and the mobiletelephone number. By way of a non-limiting example, the message may be“Here is your link to apply for credit. Opening the link grantspermission to access information from your mobile provider.” The SMSmodule 142 generates a request ID and creates the SMS request 328, whichmay include the request ID, the mobile telephone number, the message, aversion, and an authorization (e.g., “accept: application/json”). Then,the SMS module 142 sends the SMS request 328 to the SMS service 156 (seeFIG. 1 ).

In response to the SMS request 328, the SMS service 156 (see FIG. 1 )implemented by the authentication computing device(s) 150 creates andsends an SMS message 330 to the mobile device 124. The SMS message 330may be sent by the SMS service 156 (see FIG. 1 ) via a third party(e.g., using an API provided by Twilio, Inc.). Optionally, the SMSservice 156 (see FIG. 1 ) may send a response 332 (e.g., including astatus and a description) to the application processing service 140. TheSMS message 330 includes the authentication URL 318. Thus, the customer122 receives the authentication URL 318 from the application processingservice 140 (via the SMS service 156). The SMS service 156 (see FIG. 1 )may be implemented as an internal SMS service of the authenticationcomputing device(s) 150.

After the mobile device 124 receives the authentication URL 318, themobile device 124 displays a selectable visual representation 333 (seeFIG. 8 ) of the authentication URL 318. The customer 122 may use theauthentication URL 318 to visit a web address (e.g., by touching ortapping on the visual representation 333 of the authentication URL 318).The authentication URL 318 may route (represented by an arrow 334) themobile device 124 to the proxy server 136, which may redirect(represented by an arrow 336) the mobile device 124 to the deviceauthentication service 154 (see FIG. 1 ) implemented by theauthentication computing device(s) 150. The device authenticationservice 154 (see FIG. 1 ) authenticates the mobile device 124 and routes(illustrated as arrow 340) the mobile device 124 using the target URL317 to the apply website 138 (see FIGS. 1 and 9-12 ) operated by the webserver 134. As mentioned above, the target URL 317 was included in theURL request 316. A verification fingerprint may be appended to end ofthe target URL 317. The apply website 138 (see FIGS. 1 and 9-12 )obtains the SCO information and the verification fingerprint appended tothe target URL 317.

In block 350 (see FIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12) sends a request 352 for authentication status to the deviceauthentication service 154 (see FIG. 1 ) implemented by theauthentication computing device(s) 150. By way of a non-limitingexample, if the device authentication service 154 (see FIG. 1 ) isPayfone, the apply website 138 (see FIGS. 1 and 9-12 ) may use an API“/getAuthPath” to request and receive the authentication status from thedevice authentication service 154 (see FIG. 1 ). The request 352 mayinclude the verification fingerprint, a request ID generated by theapply website 138 (see FIGS. 1 and 9-12 ), and an API Client ID providedby the device authentication service 154 (see FIG. 1 ). Theauthentication status indicates whether the customer 122 wassuccessfully authenticated or was denied authentication.

In block 355 (see FIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12) receives the authentication status 356 from the device authenticationservice 154 (see FIG. 1 ). The authentication status 356 may include adescription, a Request ID, a transaction ID, an authorization signature,an authorization code, an expiration time, a path field, and a status.The path field may include the authentication status 356. By way of anon-limiting example, the path may include a green value, a yellowvalue, and a red value.

In decision block 360 (see FIG. 7 ), the apply website 138 (see FIGS. 1and 9-12 ) decides which action to take based on the authenticationstatus 356. When the authentication status 356 indicates that thecustomer 122 was not successfully authenticated (e.g., the path fieldstores the red value), in block 365 (see FIG. 7 ), the apply website 138(see FIGS. 1 and 9-12 ) sends an instruction to the mobile device 124 todisplay a message informing the customer 122 that they were notauthenticated. Then, the method 300 terminates.

On the other hand, when the authentication status indicates that thecustomer 122 was successfully authenticated (e.g., the path field storesthe green or yellow values), in block 370 (see FIG. 7 ), the applywebsite 138 (see FIGS. 1 and 9-12 ) sends an instruction 372 to themobile device 124 to prompt the customer 122 to consent to the applywebsite 138 acquiring the customer information 174 (see FIG. 1 ) fromthe carrier 170 (see FIG. 1 ). For example, in block 370 (see FIG. 7 ),the instruction 372 may instruct the mobile device 124 to display adialog box or screen 374 (see FIG. 9 ) requesting consent. Referring toFIG. 9 , the screen 374 may display a selectable user input 376 thatwhen selected indicates the customer 122 consents.

Referring to FIG. 6 , in block 375 (see FIG. 7 ), the apply website 138(see FIGS. 1 and 9-12 ) operated by the web server 134 receives anindication 378 that the customer 122 consents.

In block 380 (see FIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12) sends an eligibility request 382 to the device authentication service154 (see FIG. 1 ) implemented by the authentication computing device(s)150. By way of a non-limiting example, if the device authenticationservice 154 (see FIG. 1 ) is Payfone, the apply website 138 (see FIGS. 1and 9-12 ) may use an API “/eligibility” to request and receiveeligibility from the device authentication service 154 (see FIG. 1 ).The eligibility request 382 may include the mobile telephone number, aversion, an access token, an accept field, a request ID generated by theapply website 138 (see FIGS. 1 and 9-12 ), and a minimum trust score.The minimum trust score may be determined based on the path field. Forexample, the minimum trust score may be assigned a first value (e.g.,300) when the path field stores the green value and a second value(e.g., 500) when the path field stores the yellow value. The secondvalue may be larger than the first value. The apply website 138 (seeFIGS. 1 and 9-12 ) may use the token service 160 (see FIG. 1 )implemented by the authentication computing device(s) 150 to obtain theaccess token.

In block 385 (see FIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12) receives a response 386 to the eligibility request 382 from the deviceauthentication service 154 (see FIG. 1 ) implemented by theauthentication computing device(s) 150. The response 386 may include adescription, a request ID, a Transaction ID, the mobile telephonenumber, a line type, a carrier, a country code, an eligibilityindicator, and a status. By way of a non-limiting example, theeligibility indicator may be implemented as Boolean. Thus, theeligibility indicator may be either “TRUE” or “FALSE.”

In decision block 390 (see FIG. 7 ), the apply website 138 (see FIGS. 1and 9-12 ) decides which action to take based on the eligibilityindicator. When the eligibility indicator is “FALSE,” in block 392 (seeFIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12 ) creates anelectronic credit application 432 (see FIG. 11 ). On the other hand,when the eligibility indicator is “TRUE,” in block 394 (see FIG. 7 ),the apply website 138 (see FIGS. 1 and 9-12 ) sends a customerinformation request 395 to the device authentication service 154 (seeFIG. 1 ). By way of a non-limiting example, if the device authenticationservice 154 (see FIG. 1 ) is Payfone, the apply website 138 (see FIGS. 1and 9-12 ) may use an API “/identity” to request and receive customerinformation from the device authentication service 154. The customerinformation request may include the mobile telephone number, a version,the access token, accept (e.g., “application/json”), a request ID, aconsent status, a consent timestamp, a consent grant ID, and a consentdescription.

Referring to FIG. 1 , the pre-fill service 158 may send a request to thecarrier 170 for at least some of the customer information 174. When thecarrier 170 responds with the customer information 174, the pre-fillservice 158 provides the customer information 174 to the deviceauthentication service 154.

Referring to FIG. 6 , the device authentication service 154 (see FIG. 1) uses the customer information 174 (see FIG. 1 ) to create a pre-fillresponse 396 and sends the pre-fill response 396 to the web server 134in response to the customer information request 395. In block 398 (seeFIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12 ) receives thepre-fill response 396. The pre-fill response 396 may include one or moreof the following pieces of pre-fill information:

1. Description;

2. Request ID;

3. Transaction ID;

4. Audit Key;

5. Timestamp;

6. Mobile Telephone Number;

7. Line Type;

8. Carrier;

9. Country Code;

10. Individual;

11. First Name;

12. Last Name;

13. Address;

14. Extended Address;

15. City;

16. Region;

17. Postal Code;

18. Email Address; and

19. Status.

Then, in block 400 (see FIG. 7 ), the apply website 138 (see FIGS. 1 and9-12 ) creates the electronic credit application 432 (see FIG. 11 ) anduses at least a portion of the pre-fill information (illustrated aspre-filled information 434 in FIG. 11 ) to pre-fill the electroniccredit application 432.

In block 405 (see FIG. 7 ), the apply website 138 (see FIGS. 1 and 9-12) sends an instruction 406 to the mobile device 124 that instructs themobile device 124 to display the electronic credit application 432 (seeFIG. 11 ) to the customer 122. Referring to FIG. 11 , the electroniccredit application 432 may require customer supplied information 408such as one or more of the following:

1. Last four numbers of the social security number (“SSN”) of thecustomer 122;

2. The date of birth of the customer 122; and

3. Annual net income of the customer 122.

Referring to FIG. 6 , the apply website 138 (see FIGS. 1 and 9-12 )receives a submitted application 412 including the customer suppliedinformation 408 (see FIG. 11 ) in block 410 (see FIG. 7 ).

Then, in decision block 415 (see FIG. 7 ), the application processingservice 140 determines whether to approve or deny the submittedapplication 412.

When the application processing service 140 decides to deny thesubmitted application 412, the application processing service 140 mayinstruct the mobile device 124 to display a denial page or screen (notshown). Then, the method 300 terminates.

On the other hand, when the application processing service 140 decidesto approve the submitted application 412, in block 420 (see FIG. 7 ),the application processing service 140 dynamically generates the paymentbarcode 274 associated with an amount of credit awarded to the customer122 and sends the payment barcode 274 in a message 422 to the mobiledevice 124. The message 422 may also instruct the mobile device 124 todisplay an approval page or screen 416 (see FIG. 12 ) that includes thepayment barcode 274, which contains encrypted payment information.

In block 425 (see FIG. 7 ), the application processing service 140receives a payment request from the SCO device 110 including the paymentbarcode 274 along with transaction information. Referring to FIG. 6 , inthe embodiment illustrated, a payment request 426 is sent by the SCOdevice 110 to the security gateway 132, which forwards the paymentrequest 426, as a payment request 428, to the application processingservice 140.

In block 430, the application processing service 140 approves andapplies the credit to the transaction. Thus, at this point, theapplication processing service 140 successfully awarded the credit tothe customer 122 and applied that credit to the purchase the item(s) 128(see FIG. 1 ) at the SCO device 110. Then, the method 300 terminates.

FIG. 13 is a flow diagram of a method 500 performed by the mobile device124 (see FIGS. 1, 6, and 8-12 ). Referring to FIG. 1 , by way of anon-limiting example, the method 500 (see FIG. 13 ) may be performed atleast in part by the text application 116 and the web browser 118 bothexecuting on the mobile device 124.

In first block 510 (see FIG. 13 ), the mobile device 124 receives theSMS message 330 (see FIG. 6 ) with the authentication URL 318 (see FIG.6 ) from the SMS service 156 implemented by the authentication computingdevice(s) 150. Then, in block 520 (see FIG. 13 ), the text application116 displays the visual representation 333 (see FIG. 8 ) of theauthentication URL 318 (see FIG. 6 ) to the customer 122.

In next block 530 (see FIG. 13 ), the mobile device 124 visits the applywebsite 138 using the authentication URL 318 (see FIG. 6 ). In block 530(see FIG. 13 ), the text application 116 receives an indication from thecustomer 122 that the customer 122 would like to visit theauthentication URL 318 (see FIG. 6 ). For example, referring to FIG. 8 ,the customer 122 may click on the visual representation 333 (see FIG. 8) of the authentication URL 318 (see FIG. 6 ), which may cause the textapplication 116 to launch the web browser 118 and direct the web browser118 to visit the authentication URL 318. After the device authenticationservice 154 authenticates the mobile device 124, the apply website 138receives the authentication status 356 (see FIG. 6 ) from the deviceauthentication service 154.

Referring to FIG. 13 , the decision in decision block 540 is “YES” whenthe authentication status 356 (see FIG. 6 ) indicates that the customer122 (see FIG. 1 ) was successfully authenticated. Otherwise, thedecision in decision block 540 is “NO.”

When the decision in decision block 540 is “NO,” in block 550, the webbrowser 118 (see FIGS. 1 and 9-12 ) displays information indicating thatthe credit has been denied to the customer 122. Then, the method 500terminates.

On the other hand, referring to FIG. 9 , when the decision in decisionblock 540 (see FIG. 13 ) is “YES,” the web browser 118 displays thescreen 374 in response to the instruction 372 (see FIG. 6 ) in block 560(see FIG. 13 ). As mentioned above, the screen 374 requests consent tothe application processing service 140 acquiring information from thecarrier 170 (see FIG. 1 ). The screen 374 may display the selectableuser input 376 that when selected indicates the customer 122 consents.

In block 565 (see FIG. 13 ), the web browser 118 receives the indicationthat the customer 122 (see FIG. 1 ) consents and sends the indication378 (see FIG. 6 ) to the apply website 138.

Referring to FIG. 1 , in block 570 (see FIG. 13 ), the mobile device 124receives the instruction 406 (see FIG. 6 ) from the apply website 138 todisplay the credit application 432 (see FIG. 11 ) and request thecustomer supplied information 408 (see FIG. 11 ) from the customer 122.Thus, at this point, by clicking on the visual representation 333 (seeFIG. 8 ) of the authentication URL 318 (see FIG. 6 ), the customer 122is both authenticated and has received the credit application 432 (seeFIG. 11 ) including the pre-filled information 434 (see FIG. 11 ). Inblock 575 (see FIG. 13 ), the mobile device 124 submits the creditapplication 432 (see FIG. 11 ), which includes the customer suppliedinformation 408 (see FIG. 11 ), to the apply website 138. Then, theapplication processing service 140 determines whether to grant therequested credit to the customer 122.

Referring to FIG. 13 , the decision in decision block 585 is “YES” whenthe requested credit has been granted to the customer 122. Otherwise,the decision in decision block 585 is “NO.”

When the decision in decision block 585 is “YES,” in block 580, themobile device 124 (see FIGS. 1, 6, and 8-12 ) receives the message 422(see FIG. 6 ) from the application processing service 140 (see FIGS. 1and 6 ) and displays the approval screen 416 (see FIG. 12 ). Referringto FIG. 12 , the approval screen 416 includes the dynamically generatedpayment barcode 274. Then, the method 500 terminates. At this point, thecustomer 122 (see FIG. 1 ) may use the payment barcode 274 to makepurchases. Thus, referring to FIG. 1 , the customer 122 is able to usethe payment barcode 274 (see FIGS. 6 and 12 ) at the SCO device 110 toshop immediately after approval.

Referring to FIG. 13 , when the decision in decision block 585 is “NO,”in block 590, the mobile device 124 (see FIGS. 1, 6, and 8-12 ) mayoptionally display a message indicating that the credit has been denied.Then, the method 500 terminates.

The methods 200, 300, and 500 (see FIGS. 2, 7, and 13 , respectively)allow the customer 122 to quickly apply for and use credit. This is anovel feature because it enables the offering of in-store creditdecisioning despite the customer 122 having applied via a digitalchannel. Additionally, the pre-fill capability reduces the applicationcompletion time significantly. The methods 200, 300, and 500 (see FIGS.2, 7, and 13 , respectively) may be triggered from an SCO device (e.g.,the SCO device 110) in any in-store location and completed using anyInternet enabled device (e.g., the mobile device 124).

Computing Device

FIG. 14 is a diagram of hardware and an operating environment inconjunction with which implementations of the one or more computingdevices of the system 100 (see FIG. 1 ) may be practiced. Thedescription of FIG. 14 is intended to provide a brief, generaldescription of suitable computer hardware and a suitable computingenvironment in which implementations may be practiced. Although notrequired, implementations are described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer, such as a personal computer. Generally, programmodules include routines, programs, objects, components, datastructures, etc., that perform particular tasks or implement particularabstract data types.

Moreover, those of ordinary skill in the art will appreciate thatimplementations may be practiced with other computer systemconfigurations, including hand-held devices, multiprocessor systems,microprocessor-based or programmable consumer electronics, network PCs,minicomputers, mainframe computers, and the like. Implementations mayalso be practiced in distributed computing environments (e.g., cloudcomputing platforms) where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote memory storage devices.

The exemplary hardware and operating environment of FIG. 14 includes ageneral-purpose computing device in the form of the computing device 12.Each of the computing devices of FIG. 1 (including the devices 108, 110,130, 124, 150, and 172) may be substantially identical to the computingdevice 12. By way of non-limiting examples, the computing device 12 maybe implemented as a laptop computer, a tablet computer, a web enabledtelevision, a personal digital assistant, a game console, a smartphone,a mobile computing device, a cellular telephone, a desktop personalcomputer, and the like.

The computing device 12 includes a system memory 22, the processing unit21, and a system bus 23 that operatively couples various systemcomponents, including the system memory 22, to the processing unit 21.There may be only one or there may be more than one processing unit 21,such that the processor of computing device 12 includes a singlecentral-processing unit (“CPU”), or a plurality of processing units,commonly referred to as a parallel processing environment. When multipleprocessing units are used, the processing units may be heterogeneous. Byway of a non-limiting example, such a heterogeneous processingenvironment may include a conventional CPU, a conventional graphicsprocessing unit (“GPU”), a floating-point unit (“FPU”), combinationsthereof, and the like.

The computing device 12 may be a conventional computer, a distributedcomputer, or any other type of computer.

The system bus 23 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. The system memory22 may also be referred to as simply the memory, and includes read onlymemory (ROM) 24 and random access memory (RAM) 25. A basic input/outputsystem (BIOS) 26, containing the basic routines that help to transferinformation between elements within the computing device 12, such asduring start-up, is stored in ROM 24. The computing device 12 furtherincludes a hard disk drive 27 for reading from and writing to a harddisk, not shown, a magnetic disk drive 28 for reading from or writing toa removable magnetic disk 29, and an optical disk drive 30 for readingfrom or writing to a removable optical disk 31 such as a CD ROM, DVD, orother optical media.

The hard disk drive 27, magnetic disk drive 28, and optical disk drive30 are connected to the system bus 23 by a hard disk drive interface 32,a magnetic disk drive interface 33, and an optical disk drive interface34, respectively. The drives and their associated computer-readablemedia provide nonvolatile storage of computer-readable instructions,data structures, program modules, and other data for the computingdevice 12. It should be appreciated by those of ordinary skill in theart that any type of computer-readable media which can store data thatis accessible by a computer, such as magnetic cassettes, flash memorycards, solid state memory devices (“SSD”), USB drives, digital videodisks, Bernoulli cartridges, random access memories (RAMs), read onlymemories (ROMs), and the like, may be used in the exemplary operatingenvironment. As is apparent to those of ordinary skill in the art, thehard disk drive 27 and other forms of computer-readable media (e.g., theremovable magnetic disk 29, the removable optical disk 31, flash memorycards, SSD, USB drives, and the like) accessible by the processing unit21 may be considered components of the system memory 22.

A number of program modules may be stored on the hard disk drive 27,magnetic disk 29, optical disk 31, ROM 24, or RAM 25, including theoperating system 35, one or more application programs 36, other programmodules 37, and program data 38. A user may enter commands andinformation into the computing device 12 through input devices such as akeyboard 40 and pointing device 42. Other input devices (not shown) mayinclude a microphone, joystick, game pad, satellite dish, scanner, touchsensitive devices (e.g., a stylus or touch pad), video camera, depthcamera, or the like. These and other input devices are often connectedto the processing unit 21 through a serial port interface 46 that iscoupled to the system bus 23, but may be connected by other interfaces,such as a parallel port, game port, a universal serial bus (USB), or awireless interface (e.g., a Bluetooth interface). A monitor 47 or othertype of display device is also connected to the system bus 23 via aninterface, such as a video adapter 48. In addition to the monitor,computers typically include other peripheral output devices (not shown),such as speakers, printers, and haptic devices that provide tactileand/or other types of physical feedback (e.g., a force feedback gamecontroller).

The input devices described above are operable to receive user input andselections. Together the input and display devices may be described asproviding a user interface.

The computing device 12 may operate in a networked environment usinglogical connections to one or more remote computers, such as remotecomputer 49. These logical connections are achieved by a communicationdevice coupled to or a part of the computing device 12 (as the localcomputer). Implementations are not limited to a particular type ofcommunications device. The remote computer 49 may be another computer, aserver, a router, a network PC, a client, a memory storage device, apeer device or other common network node, and typically includes many orall of the elements described above relative to the computing device 12.The remote computer 49 may be connected to a memory storage device 50.The logical connections depicted in FIG. 14 include a local-area network(LAN) 51 and a wide-area network (WAN) 52. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet. The network(s) 120 (see FIG. 1 ) may be implementedusing one or more of the LAN 51 or the WAN 52 (e.g., the Internet).

Those of ordinary skill in the art will appreciate that a LAN may beconnected to a WAN via a modem using a carrier signal over a telephonenetwork, cable network, cellular network, or power lines. Such a modemmay be connected to the computing device 12 by a network interface(e.g., a serial or other type of port). Further, many laptop computersmay connect to a network via a cellular data modem.

When used in a LAN-networking environment, the computing device 12 isconnected to the local area network 51 through a network interface oradapter 53, which is one type of communications device. When used in aWAN-networking environment, the computing device 12 typically includes amodem 54, a type of communications device, or any other type ofcommunications device for establishing communications over the wide areanetwork 52, such as the Internet. The modem 54, which may be internal orexternal, is connected to the system bus 23 via the serial portinterface 46. In a networked environment, program modules depictedrelative to the personal computing device 12, or portions thereof, maybe stored in the remote computer 49 and/or the remote memory storagedevice 50. It is appreciated that the network connections shown areexemplary and other means of and communications devices for establishinga communications link between the computers may be used.

The computing device 12 and related components have been presentedherein by way of particular example and also by abstraction in order tofacilitate a high-level view of the concepts disclosed. The actualtechnical design and implementation may vary based on particularimplementation while maintaining the overall nature of the conceptsdisclosed.

In some embodiments, the system memory 22 stores computer executableinstructions that when executed by one or more processors cause the oneor more processors to perform all or portions of one or more of themethods (including the methods 200, 300, and 500 illustrated in FIGS. 2,7, and 13 , respectively) described above. Such instructions may bestored on one or more non-transitory computer-readable media.

In some embodiments, the system memory 22 stores computer executableinstructions that when executed by one or more processors cause the oneor more processors to generate the screens illustrated in FIGS. 3-5 and8-12 and described above. Such instructions may be stored on one or morenon-transitory computer-readable media.

Mobile Communication Device

FIG. 15 is a functional block diagram illustrating the mobilecommunication device 600 that may be used to implement the mobile device124 of FIGS. 1, 6, and 8-12 . By way of non-limiting examples, referringto FIG. 15 , the mobile communication device 600 may be implemented as acellular telephone, a tablet computer, and the like. The mobilecommunication device 600 includes a central processing unit (CPU) 610.Those skilled in the art will appreciate that the CPU 610 may beimplemented as a conventional microprocessor, application specificintegrated circuit (ASIC), digital signal processor (DSP), programmablegate array (PGA), or the like. The mobile communication device 600 isnot limited by the specific form of the CPU 610.

The mobile communication device 600 also contains a memory 620. Thememory 620 may store instructions and data to control operation of theCPU 610. The memory 620 may include random access memory, ready-onlymemory, programmable memory, flash memory, and the like. The mobilecommunication device 600 is not limited by any specific form of hardwareused to implement the memory 620. The memory 620 may also be integrallyformed in whole or in part with the CPU 610.

The mobile communication device 600 also includes conventionalcomponents, such as the display device 630 and one or more user inputdevices 640 (e.g., buttons, a keypad, a keyboard, and the like). Theseare conventional components that operate in a known manner and need notbe described in greater detail. The display device 126 may beimplemented as the display device 630. The display device 630 may beimplemented as a touch display or touchscreen configured to receive userinput (e.g., selection of the selectable visual representation 333 (seeFIG. 8 ), selection of the selectable user input 376 (see FIG. 9 ),entry of the customer supplied information 408 (see FIG. 11 ),submission of information and/or agreement, and the like). By way ofnon-limiting examples, the display device 630 is operable to display thescreens and pages depicted in FIGS. 8-12 and the like.

The memory 620 stores computer executable instructions that whenexecuted by the CPU 610 cause the CPU 610 to generate the screens andinterfaces described above and displayed by the display device 630.Referring to FIG. 1 , the memory 620 (see FIG. 15 ) also stores computerexecutable instructions that when executed by the CPU 610 implement thetext application 116 and the web browser 118. Such instructions may bestored on one or more non-transitory computer-readable media. Returningto FIG. 15 , other conventional components found in wirelesscommunication devices, such as a USB interface, Bluetooth interface,camera/video device, infrared device, and the like, may also be includedin the mobile communication device 600. For the sake of clarity, theseconventional elements are not illustrated in the functional blockdiagram of FIG. 15 .

The mobile communication device 600 also includes a network transmitter650 such as may be used by the mobile communication device 600 fornormal network wireless communication with the network(s) 120 (see FIG.1 ), such as with a base station (not shown) of a cellular network. FIG.15 also illustrates a network receiver 660 that operates in conjunctionwith the network transmitter 650 to communicate with the network(s) 120(see FIG. 1 ), such as with the base station (not shown) of the cellularnetwork. In a typical embodiment, the network transmitter 650 and thenetwork receiver 660 are implemented as a network transceiver 670. Thenetwork transceiver 670 is connected to an antenna 680. Operation of thenetwork transceiver 670 and the antenna 680 for communication with thenetwork(s) 120 (see FIG. 1 ) is well-known in the art and need not bedescribed in greater detail herein.

The various components illustrated in FIG. 15 are coupled together by abus system 690. The bus system 690 may include an address bus, data bus,power bus, control bus, and the like. For the sake of convenience, thevarious busses in FIG. 15 are illustrated as the bus system 690.

The memory 620 may store instructions executable by the CPU 610. Theinstructions may implement portions of the method 500 illustrated inFIG. 13 . Such instructions may be stored on one or more non-transitorycomputer or processor readable media.

The foregoing described embodiments depict different componentscontained within, or connected with, different other components. It isto be understood that such depicted architectures are merely exemplary,and that in fact many other architectures can be implemented whichachieve the same functionality. In a conceptual sense, any arrangementof components to achieve the same functionality is effectively“associated” such that the desired functionality is achieved. Hence, anytwo components herein combined to achieve a particular functionality canbe seen as “associated with” each other such that the desiredfunctionality is achieved, irrespective of architectures or intermedialcomponents. Likewise, any two components so associated can also beviewed as being “operably connected,” or “operably coupled,” to eachother to achieve the desired functionality.

While particular embodiments of the present invention have been shownand described, it will be obvious to those skilled in the art that,based upon the teachings herein, changes and modifications may be madewithout departing from this invention and its broader aspects and,therefore, the appended claims are to encompass within their scope allsuch changes and modifications as are within the true spirit and scopeof this invention. Furthermore, it is to be understood that theinvention is solely defined by the appended claims. It will beunderstood by those within the art that, in general, terms used herein,and especially in the appended claims (e.g., bodies of the appendedclaims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that if aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to inventions containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should typically be interpreted to mean “atleast one” or “one or more”); the same holds true for the use ofdefinite articles used to introduce claim recitations. In addition, evenif a specific number of an introduced claim recitation is explicitlyrecited, those skilled in the art will recognize that such recitationshould typically be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations).

Conjunctive language, such as phrases of the form “at least one of A, B,and C,” or “at least one of A, B and C,” (i.e., the same phrase with orwithout the Oxford comma) unless specifically stated otherwise orotherwise clearly contradicted by context, is otherwise understood withthe context as used in general to present that an item, term, etc., maybe either A or B or C, any nonempty subset of the set of A and B and C,or any set not contradicted by context or otherwise excluded thatcontains at least one A, at least one B, or at least one C. Forinstance, in the illustrative example of a set having three members, theconjunctive phrases “at least one of A, B, and C” and “at least one ofA, B and C” refer to any of the following sets: {A}, {B}, {C}, {A, B},{A, C}, {B, C}, {A, B, C}, and, if not contradicted explicitly or bycontext, any set having {A}, {B}, and/or {C} as a subset (e.g., setswith multiple “A”). Thus, such conjunctive language is not generallyintended to imply that certain embodiments require at least one of A, atleast one of B, and at least one of C each to be present. Similarly,phrases such as “at least one of A, B, or C” and “at least one of A, Bor C” refer to the same as “at least one of A, B, and C” and “at leastone of A, B and C” refer to any of the following sets: {A}, {B}, {C},{A, B}, {A, C}, {B, C}, {A, B, C}, unless differing meaning isexplicitly stated or clear from context.

Accordingly, the invention is not limited except as by the appendedclaims.

The invention claimed is:
 1. A method comprising: receiving a credit request from a self-checkout (SCO) device for a new credit amount, wherein the credit request includes SCO information associated with the SCO device and a mobile device number associated with a customer, wherein the mobile device number is entered through the SCO device, and wherein the credit request is received over a security gateway; transmitting a request to obtain an authentication Uniform Resource Locator (URL), wherein the request includes the SCO information and a target URL, wherein the target URL corresponds to a website for applying for the new credit amount, and wherein when the request is received by a URL generator, the URL generator provides the authentication URL; authenticating the mobile device, wherein the mobile device is authenticated as a result of selection of the authentication URL through the mobile device; transmitting a customer information request, wherein when the customer information request is received by a carrier that provides one or more mobile services to the mobile device, the carrier provides customer information, and wherein the customer information corresponds to the customer, the mobile device, and the carrier; transmitting an electronic credit application for applying for the new credit amount, wherein the electronic credit application is automatically populated using the customer information, and wherein when the electronic credit application is received at the mobile device, the electronic credit application is presented through the mobile device; dynamically generating a code, wherein the code is dynamically generated when the electronic credit application is approved, and wherein the code corresponds to the new credit amount; transmitting the code, wherein when the code is received at the mobile device, the code is scannable by SCO device, and wherein scanning of the code causes the SCO device to transmit a payment request, transaction information, and the code over the security gateway; and using the new credit amount to process the payment request and the transaction information.
 2. The method of claim 1, wherein the credit request is received before the customer completes an in-store checkout process.
 3. The method of claim 1, wherein the customer information request is transmitted when permission has been granted by the mobile device.
 4. The method of claim 1, wherein the code is a barcode.
 5. The method of claim 1, further comprising: transmitting a message, wherein the message includes the authentication URL, and wherein when the message is received by the mobile device, the selection of the authentication URL is performed.
 6. The method of claim 1, wherein the security gateway is an endpoint configured to receive the credit request.
 7. The method of claim 1, wherein the code includes encrypted payment information, and wherein the encrypted payment information corresponds to the new credit amount.
 8. A system, comprising: one or more data processors; and a non-transitory computer-readable storage medium containing instructions which, when executed on the one or more data processors, cause the one or more data processors to perform operations including: receiving a credit request from a self-checkout fSCO) device for a new credit amount, wherein the credit request includes SCO information associated with the SCO device and a mobile device number associated with a customer, wherein the mobile device number is entered through the SCO device, and wherein the credit request is received over a security gateway; transmitting a request to obtain an authentication Uniform Resource Locator (URL), wherein the request includes the SCO information and a target URL, wherein the target URL corresponds to a website for applying for the new credit amount, and wherein when the request is received by a URL generator, the URL generator provides the authentication URL; authenticating the mobile device, wherein the mobile device is authenticated as a result of selection of the authentication URL through the mobile device; transmitting a customer information request, wherein when the customer information request is received by a carrier that provides one or more mobile services to the mobile device, the carrier provides customer information, and wherein the customer information corresponds to the customer, the mobile device, and the carrier; transmitting an electronic credit application for applying for the new credit amount, wherein the electronic credit application is automatically populated using the customer information, and wherein when the electronic credit application is received at the mobile device, the electronic credit application is presented through the mobile device; dynamically generating a code, wherein the code is dynamically generated when the electronic credit application is approved, and wherein the code corresponds to the new credit amount; transmitting the code, wherein when the code is received at the mobile device, the code is scannable by the SCO device, and wherein scanning of the code causes the SCO device to transmit a payment request, transaction information, and the code over the security gateway; and using the new credit amount to process the payment request and the transaction information.
 9. The system of claim 8, wherein the credit request is received before the customer completes an in-store checkout process.
 10. The system of claim 8, wherein the customer information request is transmitted when permission has been granted by the mobile device.
 11. The system of claim 8, wherein the code is a barcode.
 12. The system of claim 8, wherein the instructions further cause the one or more data processors to: transmit a message, wherein the message includes the authentication URL, and wherein when the message is received by the mobile device, the selection of the authentication URL is performed.
 13. The system of claim 8, wherein the security gateway is an endpoint configured to receive the credit request.
 14. The system of claim 8, wherein the code includes encrypted payment information, and wherein the encrypted payment information corresponds to the new credit amount.
 15. A computer-program product tangibly embodied in a non- transitory machine-readable storage medium, including instructions configured to cause a data processing apparatus to perform operations including: receiving a credit request from a self-checkout fSCO) device for a new credit amount, wherein the credit request includes SCO information associated with the SCO device and a mobile device number associated with a customer, wherein the mobile device number is entered through the SCO device, and wherein the credit request is received over a security gateway; transmitting a request to obtain an authentication Uniform Resource Locator (URL), wherein the request includes the SCO information and a target URL, wherein the target URL corresponds to a website for applying for the new credit amount, and wherein when the request is received by a URL generator, the URL generator provides the authentication URL; authenticating the mobile device, wherein the mobile device is authenticated as a result of selection of the authentication URL through the mobile device; transmitting a customer information request, wherein when the customer information request is received by a carrier that provides one or more mobile services to the mobile device, the carrier provides customer information, and wherein the customer information corresponds to the customer, the mobile device, and the carrier; transmitting an electronic credit application for applying for the new credit amount, wherein the electronic credit application is automatically populated using the customer information, and wherein when the electronic credit application is received at the mobile device, the electronic credit application is presented through the mobile device; dynamically generating a code, wherein the code is dynamically generated when the electronic credit application is approved, and wherein the code corresponds to the new credit amount; transmitting the code, wherein when the code is received at the mobile device, the code is scannable by SCO device, and wherein scanning of the code causes the SCO device to transmit a payment request, transaction information, and the code over the security gateway; and using the new credit amount to process the payment request and the transaction information.
 16. The computer-program product of claim 15, wherein the credit request is received before the customer completes an in-store checkout process.
 17. The computer-program product of claim 15, wherein the customer information request is transmitted when permission has been granted by the mobile device.
 18. The computer-program product of claim 15, wherein the code is a barcode.
 19. The computer-program product of claim 15, wherein the instructions further cause the data processing apparatus to: transmit a message, wherein the message includes the authentication URL, and wherein when the message is received by the mobile device, the selection of the authentication URL is performed.
 20. The computer-program product of claim 15, wherein the security gateway is an endpoint configured to receive the credit request.
 21. The computer-program product of claim 15, wherein the code includes encrypted payment information, and wherein the encrypted payment information corresponds to the new credit amount. 